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9.  WORKSHOP  1:  What  is  a  'Capability  System  Model'? 


Dr  Michael  Ryan 
University  of  New  South  Wales 


Abstract 

In  the  current  Defence  acquisition  system,  the  Capability  System  is  described  principally  in 
the  text-based  Capability  Definition  Documents  (CDD)  set  of  documents,  which  are  provided 
to  potential  prime  contractors  through  a  formal  tendering  process.  Tenderers  are  required  to 
digest  the  CDD  in  order  to  propose  system-level  solutions  to  the  Materiel  System.  Tendered 
solutions  are  assessed  by  the  customer  for  compliance  with  the  CDD  (as  well  as  with  other 
terms  and  conditions  of  the  tender).  This  text-based  process  is  often  perceived  as  inefficient, 
with  a  high  likelihood  of  errors.  One  way  to  overcome  these  shortcomings  would  be  to  use  an 
MBSE  approach  to  pass  Capability  System  models  across  the  contractual  interface  and 
integrate  them  to  the  Materiel  System  models  included  in  the  tendered  solutions. 

In  an  MBSE-supported  system  acquisition,  however,  the  Materiel  System  is  treated  as  a  black 
box  with  its  internal  functions  being  subsequently  defined  by  the  tenderers  in  the  solution 
space  (presumably  in  a  different  way  by  each  of  the  tenderers).  To  that  end,  the  Capability 
System  Models  developed  by  the  customer  would  treat  the  Materiel  System  as  a  single  entity 
in  order  to  show  how  it  would  be  operated  and  supported  in  the  operational  environment. 
These  Capability  System  Models  would  then  be  passed  across  the  acquisition  boundary  so 
that  tenderers  can  show  how  their  tendered  Materiel  System  model  performs  in  the  context  of 
the  Capability  System  Model. 

In  order  to  be  in  position  to  use  a  Capability  System  Model  as  part  of  the  acquisition  of  a 
Materiel  System,  the  customer  must  therefore  undertake  considerable  modelling  of  the  wider 
context  of  the  Capability  System  as  well  as  of  the  relevant  Fundamental  Inputs  to  Capability 
(FIC)4  elements. 

This  workshop  examines  how  a  Capability  Systems  Model  could  be  used  to  replace  the 
existing  text-based  content  of  the  CDD  documents.  In  particular: 

•  The  workshop  will  begin  with  an  examination  of  the  existing  CDD  in  order  to  identify 
which  elements  of  the  existing  documents  can  be  replaced  by  the  Capability  System 
Model  and  which  elements  would  need  to  remain  text-based.  Relevant  documents 
include  the  Operational  Concept  Document  (OCD)  and  the  Function  and  Performance 
Specification  (FPS). 

•  Attention  will  then  turn  to  identifying  the  degree  to  which  the  customer's  business 
processes  be  modelled  in  order  to  provide  an  appropriate  level  of  abstraction  for  the 
Capability  System  Model,  so  that  it  is  suitable  to  be  used  as  the  major  artefact  to  cross 
the  acquisition  boundary. 


4  The  FIC  is  the  standard  list  for  consideration  of  what  is  required  to  generate  Defence  capability, 
comprising  organisation,  personnel,  collective  training,  major  systems,  supplies,  facilities,  support,  and 
command  &  management. 
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Specifically,  the  workshop  will  address  the  following  three  questions: 

Question  1:  What  information  and  processes  currently  described  in  text-based  systems 
acquisition  (TBSA)  (i.e.  in  the  OCD  and  FPS)  would  still  be  required  to  be  included  in  some 
way  in  the  MODEL  which  is  the  basis  of  model-based  systems  acquisition  (MBS A)? 

Question  2:  How  can  each  information/ process  be  modelled  in  MBS  A,  and  how  would  that 
be  different  to  TBSA? 

Question  3:  What  processes/ information  would  be  modelled  in  MBSA  that  do  not  exist  in 
TBSA? 

Facilitator  Biography 

Dr  Michael  John  (Mike)  Ryan  is  a  Senior  Lecturer  with  the  School  of  Engineering  and 
Information  Technology,  University  of  New  South  Wales,  at  Canberra.  He  holds  Bachelor, 
Masters  and  Doctor  of  Philosophy  degrees  in  electrical  engineering  as  well  as  a  Graduate 
Diploma  in  Management  Studies.  In  addition,  he  has  completed  two  years  formal  project 
management  training  in  the  United  Kingdom.  For  the  first  seventeen  years  of  his  career  he 
held  a  number  of  communications  engineering,  systems  engineering,  project  management, 
and  management  positions  in  the  Australian  Army.  Since  joining  UNSW,  he  has  become  an 
internationally  recognised  expert  in  systems  engineering  and  requirements  engineering,  and 
has  made  a  number  of  important  contributions  to  the  field. 

Dr  Ryan  regularly  consults  in  the  fields  of  systems  engineering,  requirements  engineering, 
communications  and  information  systems  architectures,  project  management,  and  technology 
management  including  work  for  the  2004  Athens  Olympic  Games,  the  Department  of  Defence, 
other  government  departments,  defence  industry,  and  other  industry. 

Dr  Ryan  conducts  courses  in  systems  engineering  and  requirements  engineering  as  well  as  in 
the  more-focused  application  in  Defence  acquisition,  particularly  in  the  development  of  the 
capability  development  documents  (CDD)  that  guide  acquisition  in  the  Australian 
Department  of  Defence.  He  is  the  principal  architect  of  the  Master  of  System  Engineering 
program  run  by  the  University  of  New  South  Wales  in  Canberra,  creating  the  program 
structure  and  preparing  the  appropriate  documentation  for  program  approval.  He  also 
developed  three  of  the  four  core  courses  in  that  program  and  is  currently  delivering  two  of  the 
courses  (systems  engineering  and  requirements  engineering). 

He  is  a  Fellow  of  the  Institution  of  Engineers,  Australia;  a  senior  member  of  the  Institute  of 
Electrical  and  Electronic  Engineers;  a  member  of  the  International  Council  on  Systems 
Engineering;  and  a  member  of  the  Systems  Engineering  Society  of  Australia  (in  which  he  also 
serves  on  the  management  committee  as  the  academic  representative  and  the  chair  of  the 
annual  conference).  He  is  currently  the  Chair  of  the  Requirements  Working  Group  in  the 
International  Council  on  Systems  Engineering  (INCOSE). 

Dr  Ryan  is  the  Editor-in-Chief  of  the  international  journal.  Journal  of  Battlefield  Technology,  and 
is  the  author  or  co-author  of  nine  books  and  three  book  chapters  and  over  100  technical  papers 
and  reports.  He  is  a  principal  author  of  the  Guide  for  Writing  Requirements,  recently  published 
by  INCOSE  and  is  one  of  the  authors  of  the  revised  edition  of  the  INCOSE  Systems  Engineering 
Handbook  (which  is  the  basis  of  accreditation  of  systems  engineers  internationally). 
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Workshop  Presentation  and  Outcomes 


What  is  a  Capability  System  Model? 

•  Question  1 :  Since  text-based  systems  acquisition  (TBSA) 
doesn’t  work,  what  information  and  processes  currently 
described  in  TBSA  (in  the  OCD  and  FPS)  would  still  be 
required  to  be  included  in  some  way  in  the  MODEL  which  is 
the  basis  of  model-based  systems  acquisition  (MBSA)? 

•  Question  2:  How  can  each  information/process  be  modelled 
in  MBSA,  and  how  would  that  be  different  to  TBSA? 

•  Question  3:  What  processes/information  would  be  modelled 
in  MBSA  that  do  not  exist  in  TBSA? 


Systems  Acquisition  in  Defence 
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Major  Artefacts 


Acquisition  Phase 


Conceptual 

Design 

Preliminary 

Design 

Detailed 

Design  and 
Development 

Construction 

and/or 

Production 

Stakeholder 

Requirement 

Document 

(SRD) 


Functional  Baseline 
(System  Specification) 

CONTRACT 


Allocated  Baseline 
(Development  Specification) 


Product  Baseline 
(Product  Specification) 


Operational  Function 

Concept  and 

Document  Performance 

(OCD)  Specification 

(FPS) 

Test  Concept  Document  (TCD) 

Capability  Definition  Documents 
(CDD) 


System 

Specification 

(SS) 


Sub-system 

Specifications 

(SSS) 


OCD  Template 

1. 

SCOPE 

3.4.2  Scenario  1  -  Scenario  Title 

1.1 

Capability  Identification 

3.4.2. 1  Summary  of  Situation 

1.2 

Document  Purpose  &  Intended  Audience 

3. 4. 2. 2  Summary  of  Military  Response 

1.3 

Justification  for  Capability 

3. 4. 2. 3  Summary  of  Operational  Needs 

1.4 

System  Boundary  and  Acquisition 

3.4.3  Scenario  N  -  Scenario  Title 

Assumptions 

3.5 

Summary  of  Consolidated  Operational 

1.5 

Key  Timeframes  for  Capability 

Needs 

2. 

DEFfNmONS  AND  REFERENCED 

3.6 

Solutlon-class-Independent  Constraints 

DOCUMENTS 

4. 

EXISTING  SYSTEM 

2.1 

Referenced  Documents 

4.1 

Existing  System  Overview 

2.2 

Glossary  of  Terms 

4.2 

Existing  System  Operational  Capability 

3. 

SOLUTfON'fNDEPENDENT 

Comparison 

CAPABfUTY  NEEDS 

4.3 

Existing  System  Internal  Shortcomings 

3.1 

Mission  Overview 

4.4 

Existing  System  Planned  or  Active 

3.2 

Operational  Policies  and  Doctrine 

Upgrades 

3.3 

Capability  System  End-user  classes 

4.5 

Existing  System  Internal  User  classes 

3.4 

Summary  of  Operational  Scenarios 

4.6 

Existing  System  Internal  Functionality 

3.4.1 

Common  Scenario  Attributes 

4.7 

Summary  of  Existing  System  Internal 
Scenarios 

DfD-ENG-DEF-OCD-V2.0 
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OCD  Template 


5.  SOLUTfON'CLASS  DESCRIPTION 

5.1  Materiel  System  Description 

5.2  Mission  System  Architecture 

5.3  Materiel  System  Interfaces 

5.4  Materiel  System  Internal  User  classes 

5.5  Materiel  System  Functionality  and 
Performance 

5.6  Materiel  System  Spt  Concepts  and  Reqts 

5.7  Materiel  System  Constraints 

5.8  Materiel  System  Evolution  &  Tech  F’cast 

5.9  Summary  of  Internal  Scenarios 

5.9.1  Internal  Scenario  1 

5. 9. 1.1  Summary  of  Situation 

5.9.1 .2  Summary  of  Process  Flows 
Interactions 

5. 9. 1.3  Summary  of  System  Reqts 

5.9.2  Internal  Scenario  2  -  Scenario  Title 

5.9.3  Internal  Scenario  N  -  Scenario  Title 


6,  CONSOLIDATED  FUNDAMENTAL 
INPUTS  TO  CAPABILITY (FIC) 
REQUIREMENTS 

6.1  FIC  Related  Guidance 

6.2  Major  Systems  FIC  Element 
Requirements 

6.3  Facilities  and  Training  Areas  FIC 
Element  Requirements 

6.4  Support  FIC  Element  Requirements 

6.5  Supplies  FIC  Element  Requirements 

6.6  Organisation  FIC  Element  Requirements 

6.7  Command  and  Management  FIC 
Element  Requirements 

6.8  Personnel  FIC  Element  Requirements 

6.9  Collective  Training  FIC  Element 
Requirements 

6.10  FIC  Impacts  on  Supporting  Capabilities 

6.1 1  Summary  of  Overall  FIC  Responsibilities 

6.12  FIC  Development  Forecast 


DfD-ENG-DEF-OCD-V2.0 


FPS 


•  Specifies  formal  requirements  for  the  System. 

•  Provides  the  basis  for  design  and  qualification  testing  of  the 
system. 

•  Provides  the  vehicle  for  the  capture  of  formal,  verifiable  and 
unambiguous  requirements,  ‘distilled’  from  the  OCD. 

•  Is  intentionally  written  using  formal  language,  with  all 
requirements  in  the  FPS  traceable  to  needs  in  the  OCD. 


CDD  Guide  \/2.0 
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FPS  Template 


Section  1  -  Scope 

1.1  -  Identification 

1.2-  System  Overview 

1.3-  Document  Overview 
Section  2  -  Appiicabie  Documents 
Section  3  -  Requirements 

3.1  -  Missions 

3.2  -  System  Boundaries  and  Context 

3.3  -  Required  States  and  Modes 

3.4  -  System  Capability  Requirements 

3.5  -  Availability 

3.6  -  Reliability 


3.14-  Environmental  Impact  Requirements 

3.15  -  Useability  and  Human  Factors 

3.16  -  Security  and  Privacy 

3.17  -Adaptation  Requirements 

3.18  -  Design  and  Implementation 


Constraints 

3.19  -  System  Interface  Requirements 
Section  4  -  Precedence  and  Criticaiity  of 


Requirements 
Section  5  -  Verification 
Section  6  -  Requirements  rraceaibiVity 
Section  7  -  Notes 


3.7  -  Maintainability 

3.8  -  Deployability 

3.9  -  Transportability 

3.10  -  Environmental  Conditions 

3.11  -  Electromagnetic  Radiation 

3.12 - Architecture,  Growth  and  Expansion 

3.13 - Safety 


Workshop  Outcomes 

©What  is  a  (capability)  model? 

■  An  algorithm  is  a  model 

■  Level  of  abstraction 

■  Conceptual  model  to  executable  model 

■  Non  functional  requirements  /  constraints 

■  Expression  of  knowledge 

■  Behaviour  of  a  system  (including  over  time) 

■  Describes  the  structure  of  the  environment  and  interfaces 

■  Visible  FIC  elements  including  the  support  system 

■  Performance  and  boundaries  of  execution 

■  Describes  the  problem 

■  Captures  the  requirements 

■  Fit-for-purpose  representation  of  the  capability 

■  Structured  and  traceable  information 
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Workshop  Outcomes 

©What  is  the  purpose  of  the  (capability)  model? 

■  Develop  shared  understanding 

■  Enables  /  Documents  decision  making 

■  Knowledge  transfer 

■  To  go  to  contract  /  tender 

■  Communicate  the  capability  of  a  system  to  a  sufficient  level  of 
fidelity  (reduce  risk) 

■  Validation  baseline 

■  Integration  of  knowledge  from  lower  level  models 

■  To  describe  the  relationships  with  the  capability  of  your  other 
systems 
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